Call recording configuration in CUCM

Posted on by Admin

Related Post

Call recording configuration in CUCM

Call recording.  This boils down to capturing RTP streams and somehow matching a certain RTP stream to an extension and or user ID, so it can be archived properly on a recording server. In order to do this, two things will need to be in place:

  1. Some form of RTP stream replication/forking, so that a conversation can take place as well as a recording of this same conversation at the same time. The two most important ways to do this are either by means of SPAN on an infrastructure level, or dual media streaming (DMS) on the phone.
  2. The recording server will need to be part of the signalling (SIP), so it can determine what RTP stream belongs to which extension. 

 

 
Figure 1 shows how call recording and signalling take place. The set up below shows that RTP stream forkiing takes part on the phone, using the Built in Bridge; this is called Dual media streaming. The second method of call recording, uses SPAN-ed switch ports. It does NOT require a BIB will replicate everything based on a switch port or (voice) VLAN. Implementing SPAN, therefore also means that the recording server will need to have all the signalling available.

 

Figure 1- Call recording session flow

With call recording there are two types:

  1. automatic recording – in this case the recording session automatically establishes, when the agent call connects
  2. Application invoked recording – With this, the application invokes the recording session for an active call through TAPI or JTAPI API. This for instance a case where a supervisor wants to record an agent call for quality monitoring.
Let’s focus a bit more on automatic recording. Figure 2 below show the mechanism that is set into motion when a customer makes a call to an agent with automatic call recording enabled.
Figure 2 – Automatic Call recording

 

Because the agent has a recording profile configured on the phone, as soon as a the agent answers the call (2), CUCM will make a second call to the agent’s phone BIB, for the agents voice (3). After this CUCM will set up a call for the customers voice (4). CUCM will also start signalling a call to the recording server, through a SIP trunk, for both calls (5 and 6).   After this, the Agent IP phone, forks both the agent voice as well as the customer voice to the recorder server (where it gets mixed into a single wave file, representing a single call). 
Lets look at DMS and what configuration is required on CUCM to get it to work. (Based on CUCM 8.6.2)
 

1 – Create a SIP trunk to the recording server(s)

Create a SIP trunk device to each recording server (if redundant). This will convey the signalling between CUCM and the recording server. With any inbound call into the agent, CUCM signals the recorder, which receives and answers the recording call set up messages (through a SIP INVITE) .
Please be mind full of any codec requirement that your recording server might have. The recording codec matches the codec of the customer-agent call. This means that transcoders might be required.


 2 – Create a Route Group, List and Pattern

 As can be seen below, a 7777 pattern has been defined that uses the SIP trunk (or Routelist if you deploy more than one recorder server/ VAM (Voice Acquisition Modules, as Verint Calls them))


The picture above the gateway is called “defaultrecroderSIPTrunk”. but I assume you will come up with something more meaningful than that.


 3 – Create a recording profile

The pattern defined in the step above will be used in the Recording profile  (Recording destination Address). 

 

4 – Configure the phone for recording

The last step is to configure the phones and/or device profile to invoke call recording:

  1. Set Built in Bridge to ON (phone device settings)
  2. Configure the recording tones (phone device settigs
  3. Set the recording profile (line appearance)

The recording tones can also be set under call manager service parameters:

That wraps up my in a nutshell post on recording